The invention relates generally to computer operating systems, and deals more particularly with a computer operating system which optimizes commit processing by utilizing a two-phase commit procedure only when necessary.
This patent application is related to U.S. patent applications:
U.S. Patent Application Ser. No. 07/525,430, entitled "LOG NAME EXCHANGE FOR RECOVERY OF PROTECTED RESOURCES" filed May 16, 1990 by M. K. Ainsworth et al.;
U.S. Patent Application Ser. No. 07/525,938, entitled "RECOVERY FACILITY FOR INCOMPLETE SYNC POINTS FOR DISTRIBUTED APPLICATION" filed May 16, 1990 by M. K. Ainsworth et al.;
U.S. Patent Application Ser. No. 07/525,427, entitled "COORDINATED SYNC POINT MANAGEMENT OF PROTECTED RESOURCES" filed May 16, 1990 by M. K. Ainsworth et al., now allowed;
U.S. Patent Application Ser. No. 07/525,429, entitled "ASYNCHRONOUS RESYNCHRONIZATION OF A COMMIT PROCEDURE" filed May 16, 1990 by K. H. Britton et al., now allowed;
U.S. Patent Application Ser. No. 07/525,939, entitled "REGISTRATION OF RESOURCES FOR COMMIT PROCEDURES" filed May 16, 1990 by A. Coleman; and
U.S. patent application Ser. No. 07/526,472, entitled "COORDINATED HANDLING OF ERROR CODES AND INFORMATION DESCRIBING ERRORS IN A COMMIT PROCEDURE" filed May 16, 1990 by E. A. Pruul et al., now U.S. Pat. No. 5,165,031.
U.S. Patent Application Ser. No. 07/525,426, entitled "LOCAL AND GLOBAL COMMIT SCOPES TAILORED TO WORK UNITS" filed May 16, 1990 by B. A. Maslak et al.
The operating system of the present invention can be used in a network of computer systems. Each such computer system can comprise a central, host computer and a multiplicity of virtual machines or other types of execution environments. The host computer for the virtual machines includes a system control program to schedule access by each virtual machine to a data processor of the host, and help to manage the resources of the host, including a large memory, such that each virtual machine appears to be a separate computer. Each virtual machine can also converse with the other virtual machines to send messages or files via the host. Each virtual machine has its own CMS portion of the system control program to interact with (i.e., receive instructions from and provide prompts for) the user of the virtual machine. There may be resources such as shared file system (SFS) and shared SQL relational databases which are accessible by any user virtual machine and the host.
Each such system is considered to be one real machine. It is common to interconnect two or more such real machines in a network, and transfer data via conversations between virtual machines of different real machines. Such a transfer is made via communication facilities such as AVS Gateway and VTAM facilities ("AVS Gateway" and "VTAM" are trademarks of IBM Corp. of Armonk, N.Y.).
An application can change a database or file resource by first making a work request defining the changes. In response, provisional changes according to the work request are made in shadow files while the original database or file is unchanged. At this time, the shadow files are not valid. Then, the application can request that the changes be committed to validate the shadow file changes, and thereby, substitute the shadow file changes for the original file. A one-phase commit procedure can be utilized. The one-phase commit procedure consists of a command to commit the change of the resource as contained in the shadow file. When resources such as SFS or SQL resources are changed, the commits to the resources can be completed in separate one-phase commit procedures. In the vast majority of cases, all resources will be committed in the separate procedures without error or interruption. However, if a problem arises during any one-phase commit procedure some of the separate commits may have completed while others have not, causing inconsistencies. The cost of rebuilding non-critical resources after the problem may be tolerable in view of the efficiency of the one-phase commit procedure.
However, a two-phase commit procedure is required to protect critical resources and critical conversations. For example, assume a first person's checking account is represented in a first database and a second person's savings account is represented in a second database. If the first person writes a check to the second person and the second person deposits the check in his/her savings account, the two-phase commit procedure ensures that if the first person's checking account is debited then the second person's savings account is credited or else neither account is changed. The checking and savings accounts are considered protected, critical resources because it is very important that data transfers involving the checking and savings accounts be handled reliably. An application program can initiate the two-phase commit procedure with a single command, which procedure consists of the following steps, or phases:
(1) During a prepare phase, each participant (debit and credit) resources is polled by the sync point manager to determine if the resource is ready to commit all changes. Each resource promises to complete the resource update if all resources successfully complete the prepare phase i.e. are ready to be updated. PA0 (2) During a commit phase, the sync point manager directs all resources to finalize the updates or back them out if any resource could not complete the prepare phase successfully.
An IBM System Network Architecture SNA LU6.2 sync point architecture reference SC31-6808 Chapter 5.3 "Presentation Services--Sync Point Verbs", published by IBM Corporation, was previously known to coordinate commits between two or more protected resources. This architecture previously addressed sync point facilities consisting of a sync point manager which performed both sync point and associated recovery processing running in a single application environment. Several applications could run simultaneously in this environment. The LU6.2 architecture supports a sync point manager (SPM) which is responsible for resource coordination, sync point logging and recovery. The prior art CICS/VS environment supports such an architecture.
According to the SNA LU6.2 Architecture prior art, in phase one and in phase two, commit procedures are executed and the sync point manager logs the phase in the sync point log. Also, the sync point manager logs an identification of a logical unit of work which is currently being processed. Such logging assists the sync point manager in resource recovery or resynchronization in the event that a problem arises during the two-phase commit procedure. If such a problem arises subsequent to entering the two-phase commit procedure, the log is read and resource recovery processing takes place to bring the resources involved in the commit to a consistent state. The problems include failure of a communication path or failure in a resource manager.
The aforesaid LU6.2 sync point architecture is defined as one application environment. Every LU6.2 sync point environment runs applications for that environment. Data is typically owned by that environment and not shared outside of the environment, unless it is specifically extracted from the environment. The LU6.2 sync point architecture defines a sync point manager (SPM) model for resource coordination, recovery and sync point manager logging in a single environment. Different environments require separate sync point managers, which include separate syncpoint and recovery operations, and separate logs, even on the same physical processor. Similarly, in another prior art system control program, CICS/VS Control Program, sold by IBM Corp., all processes and most resources are owned by the environment rather than by the system.
In another prior art system control program, VM/SP Release 5, sold by IBM Corp. for supporting multiple (virtual machine) execution environments, two application programs could run in the same (virtual machine) execution environment. However, if the called application program committed file updates, this would cause the calling application program's file updates to be committed even if the files of the calling application program were not yet in a consistent state. There was no feature in this prior art system control program to separate the work of the calling application from the work of the called application. In addition, commits were limited to files and, through separate procedures, data bases.
In a subsequent prior art system control program, VM/SP Release 6, also sold by the IBM Corp. for a virtual machine environment, two application programs running on the same virtual machine (execution environment) could define different work units for their files. As a result, the files accessed by one application could be committed independently of the files accessed by the other application, and the work of one application could be done independently of the work of the other application. Also, in this subsequent prior art system control program, one application (for example, a server) could have multiple work units concurrently. Nevertheless, this subsequent prior art system control program was limited in that, although multiple resources could have the same work unit, resource updates had to be committed independently. Furthermore, each work unit was confined to an execution environment (virtual machine).
CICS/VS always uses the two-phase commit procedure, with a provision for the last-agent optimization, when coordinating commits between one or more protected resources. The last-agent optimization is an optimization for the committing of resources, and is part of the LU6.2 sync point tower architecture. Last-agent optimization is optimized for reduced communications network message traffic when committing resources. In the LU6.2 sync point architecture, one sync point manager is known as the initiator, and it has the authority to make the decision to commit or backout the synchronization point. The decision is based on the responses received from all the participants in the synchronization point during the first phase of the two-phase commit procedure. Once the decision is made, it is communicated to all the participants during the second phase of the two-phase commit procedure. When performing the last-agent optimization, the sync point manager solicits responses from all synchronization point participants except one during the first phase. The one participant not involved in the first phase is called the last agent. Once all the other participants have responded during the first phase, the initiator communicates with the last agent, deferring the commit decision to the last agent. Now, the last agent will make the decision whether to commit or back out the synchronization point, based on the responses it receives from the participants with which it communicates. Selecting a last agent reduces the message traffic between the initiator and the last agent, because work at the last agent is commited or backed out after only one message is sent from the initiator to the last agent. Committing work at all non-last agents requires that two messages be set from the initiator.
IBM Technical Disclosure Bulletin, December 1983, pages 3379-3383 discloses a presumed abort process which is an extension of a two-phase commit protocol. The presumed abort process is optimized for read-only transactions and results in reduced communications network message traffic and log writes. In a distributed database system, the actions of a transaction may occur at more than one site. Each site has a log which is used to recoverably record the state changes of the transaction status during execution of the commit protocol, and its changes to the database during execution. If a subordinate receives a prepare message for a read operation during phase one and finds that it need not do any updates, it sends a re-vote, releases its locks, and forgets the transaction. The subordinate writes no log records; as far as it is concerned it does not matter whether the transaction is ultimately aborted or committed. The subordinate, which is now known to the coordinator as read-only, will not be sent any messages by the coordinator in the second phase, if any. There will not be a second phase if the coordinator get only re-votes and it is also read only. In this case the coordinator, just like the subordinates, writes no log records for the transaction. Alternately, if the coordinator or one of the subordinates votes yes (indicating a data update and readiness to commit) and none of the others vote no (indicating a data update and unreadiness commit) then the coordinator proceeds as in other two-phase commit procedures. It is sufficient for the coordinator to include in the commit record only the identifiers of those subordinates (if any) that voted yes. Only those processes will be in the prepared state, and only they will be sent commit messages.
While this process reduces message traffic and log writes, a prepare message must still be sent to each resource manager for each work request to determine the type of commit procedure required, and the transmission and processing of this prepare message is inefficient.
In the presumed abort process, the initiator does not write any log records prior to the start of the first phase. If the transaction is completely read-only, then no log records are written, and there is no need for a second phase. If the transaction is partially read-only, then prior to the start of the second phase, the initiator writes a commit record which contains information about only those subordinates that are not read-only. The second phase of the commit procedure then commits or backs out those subordinates. After the second phase is completed, then the transaction is forgotten. Subordinates that are read-only do not write any log records, but each one of these subordinates sends one message, a read vote. For a committed partially read-only transaction, the coordinator sends two messages, prepare and commit, to the update subordinates and one message, prepare, to the read-only subordinates. While this second technique also reduces message traffic, it still requires that read-only resource managers still participate in commit activity before the actual commit request. See also "Transaction Management in the R* Distributed Database Management System" by Mohan et al, ACM Transactions on Database Systems, Vol. II, No. 4, December 1986 pages 378-396.
A general object of the present invention is to provide a computer operating system which optimizes the use of one-phase and two-phase commit procedures for resources and minimizes overhead in implementing the optimization and commit procedures.
A more specific object of the present invention is to provide a computer operating system of the foregoing type which minimizes the participation of read-only mode resource managers prior to the commit phase.